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Abstract 

Geant4 has been used throughout the nuclear and high-energy physics community to simulate 
energy depositions in various detectors and materials. These simulations have mostly been run with 
a source beam outside the detector. In the case of low-background physics, however, a primary 
concern is the effect on the detector from radioactivity inherent in the detector parts themselves. 
Prom this standpoint, there is no single source or beam, but rather a collection of sources with 
potentially complicated spatial extent. LUXSim is a simulation framework used by the LUX 
collaboration that takes a component-centric approach to event generation and recording. A new 
set of classes allows for multiple radioactive sources to be set within any number of components 
at run time, with the entire collection of sources handled within a single simulation run. Various 
levels of information can also be recorded from the individual components, with these record levels 
also being set at runtime. This flexibility in both source generation and information recording 
is possible without the need to recompile, reducing the complexity of code management and the 
proliferation of versions. Within the code itself, casting geometry objects within this new set of 
classes rather than as the default Geant4 classes automatically extends this flexibility to every 
individual component. No additional work is required on the part of the developer, reducing 
development time and increasing confidence in the results. We describe the guiding principles 
behind LUXSim, detail some of its unique classes and methods, and give examples of usage. 

1 PACS numbers: 32.50.d, 6L25.Bi 
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1 I. INTRODUCTION 



2 Geant4 is a physics process simulation package developed at CERN, initially for liigh- 

3 energy physics simulations P-[3]. In the majority of high-energy experiments, the primary 

4 particles are generated separate from the active detector elements. This provided a clean 

5 distinction in the simulation between the machinery used to generate the beam and the 

6 hardware used to measure the beam's effects. 

7 Over the years, Geant4 has been expanded to make it more useful for experiments at 

8 nuclear energies, including the category of low-background experiments such as neutrino 

9 research, searches for neutrinoless double-beta decay, and searches for WIMP Dark Matter. 

10 This expanded functionality included additional code to handle electromagnetic interactions 

11 down to 250 eV in energy, neutron interactions down to thermal energies, radioactive decays, 

12 and event generation from an arbitrary volume rather than a point or a beam. 

13 Historically, a Geant4 simulation of a low-background experiment would be run, record- 

14 ing energy depositions only from the active detector components. Inevitably, unexpected 

15 phenomena required recording data from passive components as well, to account for all en- 

16 ergy released in an event. Regardless of the time of an interaction, additional code had to 

17 be written into the simulation for every component that recorded data. It was rarely known 

18 a priori which parts were altering the observed energy depositions, so more and more com- 

19 ponents had to be included in the data record, leading to a large proliferation of additional 

20 code within the simulation. 

21 In addition to data recording, low-background experiments must pay special attention to 

22 the energy sources of each individual component and material within the detector, support 

23 structure, shielding, and environment. These sources include cosmic ray spallation, intrinsic 

24 radioactivity, and surface contaminants, and multiple sources are frequently required for 

25 a single component. Although educated guesses could be made, it is difficult to know 

26 beforehand which sources in which components are the most relevant to the experiment. 

27 Sources therefore have to be added to more and more components, with additional code 

28 required for each combination. 

29 In the end, it is much easier to simply ensure that all parts have the ability to record 

30 data and carry multiple radioactive loads. The code to handle data recording and the code 

31 to handle intrinsic radioactivity is largely independent of the part itself. This implies the 
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1 need for a set of classes that provide a consistent approach to both requirements. This paper 

2 includes details on such a new set of classes. 

3 The new features described in this paper is useful across multiple current and future 

4 experiments involving nuclear-scale energies and low levels of background activity. They 

5 were therefore developed into a generalized code base called LUXSim. These features include 

6 creating multiple, simultaneous primary particle types and composite sources, as well as 

7 allowing those particles to be generated from multiple volumes of arbitrary spatial extent. 

8 In addition to these physics-motivated features, LUXSim has a set of guiding principles to 

9 increase reliability and reproducibility, and to reduce the time and effort required to use or 

10 expand on the package. 

11 In Section [IT], we briefly cover the LUX experiment to provide context for the simulation 

12 package, and in Section ITlT] we describe the guiding principles for LUXSim. In Section [TV] we 



13 discuss the details of the subsystems that make up the Geant4 user code within LUXSim. 

14 In Section |V] we describe how the resulting data can be post-processed to make it similar 

15 to the data stream coming from the physical electronics. In Section |VI| we exercise the 

16 basic functionality of LUXSim, comparing simulation data with experimental data from a 

17 single-phase detector, as well as making preliminary predictions relevant for optical photon 

18 collection. In Section IVIII we describe how to use the LUXSim infrastructure for other 

19 experiments. 



20 II. THE LUX EXPERIMENT 

21 LUX is a search for WIMP Dark Matter based at the Sanford laboratory in Lead, South 

22 Dakota [H [5]. LUX utilizes a dual-phase detector with a 300-kg liquid xenon target (100 kg 

23 fiducial mass) to obtain a projected sensitivity in the WIMP-nucleon elastic scattering cross 

24 section of 7 x 10~^^ cm^ for a 100-GeV WIMP. To attain this level of sensitivity, there can 

25 only be 2 background events in the 5-25 keV region of interest after 300 days of running, 

26 qualifying LUX low-background experiment. 

27 The detector is comprised of a titanium cryostat inside a titanium vacuum vessel. The 

28 photomultiplier tubes used to detect the scintillation light resulting from charged particle 

29 interactions are housed in monolithic copper frames. The LUX detector will be installed in 

30 an 8-meter-diameter water tank to provide shielding from external gammas and neutrons. 
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FIG. 1. Photo of the LUX detector, and an engineering rendering. Only the 
top of the outer titanium vessel is present in the photo. 

1 This water tank will be instrumented with photomultiplier tubes to create a tag for muons 

2 that pass close to the active xenon volume. The water tank also thermalizes and captures 

3 neutrons, and by adding gadolinium to the water, the neutron-tagging efficiency is increased 

4 because of the resulting 8-MeV gamma cascade. Figure [T] shows the LUX detector itself. 

5 A particle interaction in the LUX detector generates two signals. The first is the primary 

6 flash of scintillation light created during the initial xenon or electron recoil, referred to as 

7 the SI light. The recoil also creates ionization, and those liberated electrons are drifted up 

8 by an electric field to a gaseous volume just below the top bank of photomultiplier tubes. A 

9 field gradient across the liquid / gas boundary extracts the drifted electrons from the liquid 

10 surface, and a high electric field within the gaseous volume causes the drifting electrons to 

11 create scintillation light, producing a second scintillation pulse referred to as S2. A detailed 

12 analysis of this sort of signal from dual-phase detectors has been studied by previous WIMP 

13 searches such as XenonIO P [7j and Zeplin-III [8l[9]. 
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1 III. THE LUXSIM GUIDING PRINCIPLES 



2 Basic physics features of LUXSim were listed in Section [T| but there are other features 

3 that should be incorporated to make the Monte Carlo simulation code itself easier to use 

4 and develop. In this section, we cover the desired feature set for LUXSim and how these 

5 features are implemented. 



6 1. Keep LUXSim simple for users 

7 LUXSim is developed primarily by a subsection of the LUX collaboration, but with the 

8 intent that anyone in the collaboration can use the simulation to produce results on a very 

9 short time scale. LUXSim is therefore controlled mainly through the use of macro commands 

10 issued at run time, rather than recoding and recompiling. Because lower-level coding and 

11 recompilations are kept to a minimum, there is less chance for an error to make its way into 

12 the code base. 

13 LUXSim, like the underlying Geant4 framework, is not intended to handle all conceivable 

14 situations "out of the box" . Users are encouraged, however, to request new features. If those 

15 features are simple to build into the code and do not interfere with the performance and 

16 results of the current code base, they are implemented. If those features require a more 

17 fundamental code change, they are evaluated for universality — if an appreciable number of 

18 users would make use of the new feature, it is implemented. Ultimately, to handle very 

19 specific cases that are not a standard part of LUXSim, users work with the developers to 

20 ensure quality results. 

21 A directory hierarchy was created to allow for conceptual segregation of the LUXSim 

22 subsystems. In the examples of user code distributed with the Geant4 package, all source files 

23 are contained in a single directory called "src" , and all header files in an "include" directory. 

24 Within LUXSim, there are approximately four dozen code files, and placing them all in 

25 a single directory would make conceptual separation difficult. LUXSim files are therefore 

26 spread across separate "generator", "geometry", "io", "management", "physicslist" , and 

27 "processing" directories. Each directory contains its own "src" and "include" directories. 
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1 2. Scalability 



2 Because it is based on Geant4, LUXSim is a C++ program, allowing for highly object- 

3 oriented programming techniques. LUXSim relies heavily on subclassing and multiple in- 

4 stances. For example, LUXSim has a generic detector class from which all possible geome- 

5 tries inherit. This allows for one geometry to be quickly and easily swapped in for another 

6 at run time. 

7 We also made heavy use of C++ container classes, to allow for scalability to meet cur- 

8 rent and future needs within the simulation. To this end, we employ vectors, strings, and 

9 stringstreams wherever possible, and have restricted the use of hard-coded array sizes and 

10 character arrays with a finite size. 

11 3. Reproducibility 

12 From time to time, two ostensibly similar Geant4 simulations can produce very different 

13 results. These differences can be the result of various discrepancies between the simulations, 

14 e.g, in the geometry, the material properties, the particle interaction models, or the gen- 

15 eration mechanism for primary particles. It can be extremely difficult to reproduce those 

16 simulations to identify the underlying cause of the differences, especially if months or years 

17 have passed since the programs were run. 

18 We have therefore built automatic record-keeping into the LUXSim output file. Each file 

19 contains a text header that contains valuable pieces of information required to know exactly 

20 how the data in the file was generated. That information includes which computer ran the 

21 simulation, its operating system, the version of Geant4 used, a time/date stamp, and the 

22 seed used to initialize the random number generator. Within the LUX collaboration, we 

23 use the Subversion ("SVN") software management system [TU], and the output file header 

24 includes not only the specific LUXSim SVN version, but any differences between the code 

25 that ran the simulation and the code checked in under that version in the software repository 

26 (i.e., the SVN "diffs"). 

27 The header information is written to every output file to eliminate concerns over keeping 

28 separate log files associated with the individual simulation data files. The header size can 

29 depend greatly on the amount of code that may have been changed between the files in the 
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1 central SVN repository and the files on the local hard drive, but rarely exceeds more than 

2 a few kilobytes. 



4- Agnostic binary output format 

The data generated with LUXSim are recorded to a binary file with a custom, well- 



5 documented format, described in Section IV G LUXSim users can employ any software 



6 package to analyze the simulation data. LUXSim includes routines to read the data files 

7 using either ROOT [llj or Matlab |T2]. This allows members of the LUX collaboration to use 

8 either package for analysis and processing. Neither package is required for the simulation 

9 to run since LUXSim does not use any ROOT or Matlab libraries or classes within the 

10 simulation code. 



11 5. Self -registering objects 

12 Within LUXSim, there is a manager class called LUXSimManager. This class contains 

13 registration methods that all classes within LUXSim use. The manager contains a list of all 

14 pointers to all subsystems within LUXSim, and handles the communications between the 

15 various parts of the simulation. As such, pointers do not have to be explicitly passed from 

16 object to object, and all parts of the simulation have automatic access to information from 

17 any class within LUXSim via the LUXSimManager. 

18 The classes within LUXSim must therefore respect the automatic registration with 

19 LUXSimManager. This automatic registration is part of the built-in framework, and simply 

20 inheriting from various LUXSim classes performs the job without requiring additional code. 

21 Additional details of the manager are discussed in Section |IV A 



22 6. Component- centric approach to event generation and recording 

23 LUXSim utilizes a custom class called LUXSimDetector Component. This class itself in- 

24 herits from the Geant4 class G4PVPlacement, and is therefore intimately associated with 

25 the geometry of any given detector. By recasting all physical volumes as LUXSimDetec- 

26 torComponents, we ensure that all components automatically have access to the LUXSim 
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infrastructure. 

Part of this infrastructure includes methods for each component to store its own radioac- 
tive identities and rates. The components can also store their own record levels, so that 
specific information about particles passing through or interacting within the volume can be 
recorded, or not, as specified by the user at run time. While the LUXSim code base cannot 
possibly anticipate every question a user may want to answer by running a simulation, we 
have attempted to build in a great deal of flexibility so that users can decide for them- 
selves whether they are interested in energy depositions either within the active detector 
components or some nearby, inert, supporting structure. 

In Geant4, an "event" is all the interactions deriving from the full complement of primary 
particles that are generated in a single loop. The primary particles can themselves be 
radioactive nuclei, which have finite lifetimes. Because of the stochastic nature of particle 
decays, it is entirely possible for interactions from one event to occur earlier in time that 



interactions from a previous event (see Section IV D 2 ) 



Details of the LUXSimDetectorComponent class are available in Sections IV B , IV D , and 
HVGl 



IV. LUXSIM SUBSYSTEMS 

LUXSim uses a component-centric approach to creating a Geant4-based simulation, which 
means the detector components themselves store their own levels of radioactivity and step- 
by-step energy depositions. The internal management and information flow, however, can- 
not be tied to the components because they change from geometry to geometry. LUXSim 
therefore makes use of a manager class to handle inter-class communications. 

The flow of information is shown in Fig. [2j The user controls the simulation via macro 
commands, which are processed by the manager. Before the simulation actually begins, the 
manager performs final calculations and bookkeeping based on the latest user commands. 

In this section, we detail the subsystems within LUXSim. 
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A. The LUXSim Manager Class 



The LUXSimManager class sits in the middle of the information flow within LUXSim. It 
contains registration methods for all the other LUXSim classes, and contains access methods 
so that any subclass can retrieve those pointers. In turn, all the other classes store a pointer 
to the manager singleton to provide two-way communication within the simulation. These 
registration methods are in the class constructors so that any objects that inherit from these 
LUXSim classes automatically become a part of the larger framework. 

The manager class processes user commands, sets sources and record levels within the 
detector components, sets flags and parameters for the physics models, and provides control 
over the randomization seed. Once the simulation parameters are set, it performs final 
calculations regarding source strength ratios, creates and makes accessible the reproducibility 
information stored in the header, and assigns integer indices to the volume names to reduce 
the size of the output file. 

At the beginning of the simulation, the manager appends a ".tmp" extension to the 
output file name. In addition, it keeps a vector list of all detector components, as well 



Macro commands 
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Geometry ^< — > Manager 



Physics 




Processing 




Output 



FIG. 2. Information flow in LUXSim. The manager handles all communi- 



cation between subsystems, while the detector components in the geometry 



subsystem hold the vital information. 
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1 as the sum total of all radioactivity within each component. The manager also records 

2 the primary particle information for every event, which is very important if the particle 

3 is randomly selected from an extended decay chain or generated from anywhere within a 

4 three-dimensional object. The manager controls which physical volume will contain the 

5 next event based on the pre-calculated ratios of activity. While the simulation is running, 

6 step information is passed along to the manager for it to parcel out to the correct detector 

7 component object. Finally, if the simulation ends cleanly, the manager removes the ".tmp" 

8 extension to signify a complete and whole data file. 

9 If the simulation does not end cleanly, the user may use routines specifically written to 

10 recover as many full, reliable events as may have been recorded in the data file. In this case, 

11 however, the number of events contained in the data file would have to be adjusted, and 

12 the header file of the cleaned data set re-written. Because of the uncertainty surrounding 

13 incomplete datafiles, users are encouraged to simply re-run the simulation. 



14 B. Geometry and LUXSim Detector Components 

15 Rather than using the Geant4 class G4PVPlacement for instantiating physical volumes, 

16 every physical volume in LUXSim has been recast as a LUXSimDetector Component, which 

17 inherits from G4PVPlacement. This new class has the features that satisfy the requirements 

18 for consistent treatment of data recording and event generation described in Section |T} 

19 The LUXSimDetectorComponent class contains the record level associated with any par- 

20 ticular physical volume. The record level determines the amount of information recorded to 



21 the output file (see Section IV G). The user can specify the record level for any component 

22 with a simple macro command, thus choosing at run time which components will serve as 

23 particle "detectors" rather than hard-coding Geant4-style sensitive detectors. The record 

24 levels are covered in detail in Section IIVGI 

25 A LUXSimDetectorComponent can also have an arbitrary number of radioactive sources 

26 associated with it, each with an individual activity level. At the beginning of the run, 

27 the /LUXSim/beamOn macro command calculates the total activity in all components. 

28 During the running of the simulation, the manager randomly chooses both the component 

29 and the source within the component, all weighted by the specified activities. The timing, 

30 energy, momentum, and secondary particle chains for each event are handled by a variety 
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1 of generators, described in Section IV D Additionally, a volume- sampling method is used to 

2 determine the starting position for the primary particles. The detector component's center 

3 coordinates in the global reference frame are calculated, as well as its spatial extent in the x, 

4 y, and z directions and its orientation within the global reference frame. The vertex location 

5 of the event is passed to the PrimaryGeneratorAction, which then passes the simulation 

6 processing to the internal Geant4 libraries. 

7 This type of component-centric approach to event generation and information recording 

8 makes heavy use of the two-way communications between the geometry subsystem and 

9 the LUXSimManager class. The macro commands for geometry construction, radioactive 

10 and particles sources, and detector record levels are passed to the manager. Before the 

11 simulation starts, those settings are accessed by the geometry sub-system, and stored in the 

12 LUXSimDetector Component classes. That stored information is then accessed through the 

13 manager by other sub-systems: source choices are passed to the PrimaryGeneratorAction, 

14 record level choices are passed to the input/output subsystem, and so on. 

15 Four default detector geometries are available with various options, including LUXl.O 

16 (the full detector system), LUXO.l (a prototype detector for studying engineering, xenon 

17 liquification and purification, and signal handling), the LLNL single-phase detector (see 



18 Section VIA), and an empty LUX cryostat to study the effects of the water shield without 

19 the complex internal structure of the LUXl.O detector. The LUXl.O geometry was designed 

20 with two purposes: providing a background model from both internal detector components 

21 and external sources, and determining the light response of the detector. The simulated 

22 LUXl.O geometry is based on all available engineering diagrams and specifications, ensuring 

23 the highest possible confidence in the simulation results. 

24 To be able to select the different detectors at run time with macro commands, each 

25 detector inherits from a base LUXSimDetector class. The outermost volume of the specific 

26 detector (e.g, the cryostat of the LUXl.O detector, or the vacuum vessel of the LLNL single- 

27 phase detector) is incorporated in the simulation as a LUXSimDetectorComponent after the 

28 user choice is made, but before the simulation starts running. These geometries can exist as 

29 stand-alone detectors, or encased inside the LUX water tank. See Figs. [3] and |4] for images 

30 of the LUXl.O detector. 

31 Dual-phase detectors incorporate wire grids and meshes to define the electric field vol- 

32 umes. Within the LUXl.O geometry, these thousands of wires are placed individually to 
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provide accurate handling of the optical photons. There is, however, an option to remove 
grid wires from the LUXl.O and LUXO.l detectors for simulations that do not require optical 
physics. 

Whenever multiple copies of similar components exist, component classes are used to 
avoid code duplication. One example is the grid class used for both the LUXl.O and 
LUXO.l detectors. A single call to this grid class, utilizing appropriate dimensions and 
parent volumes as parameters, can create grids for multiple detectors. A second example is 
the photomultiplier tubes, where a single tube geometry is created, and multiple instances 
created as necessary to fully populate the detector. This approach follows established Geant4 
practices. 



FIG. 3. The LUXSim rendering of the internal components of the LUXl.O 
detector. The simulated detector includes the major components that af- 
fect the optical response and background, including the Hamamatsu R8778 
PMTs, the reflective PTFE surfaces, and the grid wires and frames. All 122 
PMTs are present in the simulation, although the visualization hides some 
of them. Compare to Fig. [TJ 
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FIG. 4. LUXSim rendering of the LUXl.O detector inside the water shield. 
The water shield has 20 ten-inch Hamamatsu R7081 PMTs for the Muon 
Veto System. Also visible in this image are the guide tubes for the calibration 
source, located just outside of the cryostat. 
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1 C. Optical properties 



2 Energy deposition in the LUX detector will be measured in both scintillation and ioniza- 

3 tion channels. Both of these channels are measured using scintillation light. The scintillation 

4 channel is measured with primary scintillation (SI), and the ionization channel is measured 

5 with secondary scintillation (S2). The SI and S2 light collection efficiency must therefore be 

6 very well understood to properly calibrate the detector. The collection efficiency value is not 

7 constant, but is a function of effects such as position, material reflectivity, and scattering 

8 and absorption lengths in the xenon. 

9 Because of the low-energy deposition that characterizes a possible WIMP signal, the 

10 amount of scintillation light generated may be quite small. LUXSim must therefore handle 

11 scintillation light collection down to the single-photon level, making optical modeling of 

12 paramount importance. The LUX experiment needs to detect the SI and S2 signals from 

13 recoils within the liquid xenon target, and LUXSim needs to be able to accurately reproduce 

14 the spatial and timing characteristics of those pulses. Twin arrays of Hamamatsu R8778 

15 PMTs detect the scintillation light, which is narrowly peaked at 178 nm. Light collection 

16 is enhanced by fully encompassing the active region with sheets of PTFE, which has a high 

17 reflectivity for UV photons. Detailed modeling of the effects of these materials is crucial in 

18 LUXSim. 

19 The optical properties of liquid xenon at 178 nm have been studied in several different 

20 experiments [13] . One critical parameter of liquid xenon is the refractive index, which the 

21 XenonIO collaboration set at 1.69 at 178 nm. This value was combined with data on the 

22 liquid xenon refractive index from 361.2 to 643.9 nm [H], and a polynomial fit used to 

23 interpolate between the points. Another critical optical parameter is the Rayleigh (lossless) 

24 scattering length, which has been measured to be 30 cm [151 [16] . 

25 A third critical optical parameter of liquid xenon is the absorption length of its own 

26 scintillation light. Pure liquid xenon is expected to be transparent to its own scintillation 

27 light [13 . Loss mechanisms are dominated by impurities, including in particular oxygen and 

28 water [18] . The expected absorption coefficients for these impurities are convolved with the 

29 xenon scintillation spectrum, and the characteristic absorption length is fit to the result for 

30 a given impurity concentration. The LUX getter is rated for impurity removal below the 

31 ppb level; this has led to a conservative estimate of a minimum absorption length of 100 m, 
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1 which is used as the LUXSim default. 

2 PTFE reflectivity is very important for estimates of overall light collection in LUX, as 

3 well as light collection dependence on event position. Because any given photon can reflect 

4 many times off the PTFE walls, a relatively small change in the PTFE reflectivity can result 

5 in a large change in the final light collection efficiency. Measurements performed on PTFE 

6 samples from a variety of preparation and treatment types show a very large variation 

7 in their overall reflectivities, as well as variations in their specular and diffuse responses 

8 [UlEO]. LUX PTFE samples were measured in gas to determine their predicted reflectivity, 

9 with the results implemented in LUXSim. Separate reflectivity values are implemented at 

10 the liquid and gas xenon interfaces, as PTFE reflectivity in liquid xenon is predicted to 

11 increase substantially from that measured in gas due to the change in refractive index of 

12 the incident medium. The reflectivity model used in LUXSim for PTFE is 100% diffuse, 

13 although measurements from Ref. [19] indicate that the specular component of LUX PTFE 

14 increases with increasing angle of incidence. Note that in this paper, the angle of incidence 

15 is measured with respect to normal. The effects of diffuse and specular reflection models 



16 and the default values used for PTFE reflectivity in LUXSim are discussed in Section VI B 

17 The geometry includes the electric field grids used within the active region. The LUX 

18 field grids are strung steel wire, with 98-99% geometric transparency at 0° incidence with 

19 respect to normal. The exception is the anode grid, which is a mesh of 88% transparency at 

20 normal incidence. The grids are modeled as individual wires, as their geometric transparency 

21 decreases with increasing incidence angle. Very little data exists for the reflectivity of steel 

22 at 178 nm in a high refractive index medium. LUXSim uses a conservative 10% reflectivity 

23 for baseline estimates of light collection efficiency; studies of LUX light collection using 

24 LUXSim with default optical parameters have shown that a high grid reflectivity of 100% 

25 can boost light collection by ~10% for any given PTFE reflectivity. 

26 The LUX R8778 PMTs feature a fused silica window in front of the photocathode. This 

27 feature is implemented in LUXSim in order to include the effects of photon reflection from the 

28 quartz windows, which is particularly important for photons incident on the PMT windows 

29 at high angles of incidence. Values of refractive index at UV wavelengths are found in 

30 pT], with temperature-dependent changes calculated using [22]. Results yield an expected 

31 refractive index of 1.59 at 178 nm. 

32 LUXSim also includes optical properties defined at lower wavelengths appropriate for 
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water Cerenkov processes. These properties facilitate the study of the optical response of 
the muon veto implemented in the LUX water shield. Refractive indices for water are taken 
from [23J ; absorption lengths are taken from several sources . 

D. The event generator subsystem 

The LUXSimSource class provides a general framework for all the event generators in 
LUXSim. Currently, the list of generators includes all single-radionuclide decays, ^38^ 
232rpj^ radioactive decay chains, an AmBe source with neutrons and associated gammas, 
252q£ fission neutrons and gammas, and a cosmic muon generator with spallation neu- 
trons. Each source inherits from the base class and sets its own values for the particle 
type, energy, and direction. A vector of all the source types is kept in a separate class, the 
LUXSimSourceCatalog, and is used for setting sources in materials and generating events. 
The LUXSimPrimaryGeneratorAction class can handle both LUXSim-style sources speci- 
fied through macro commands, or generate an event defined by standard Geant4 General 
Particle Source (G4GPS) commands. The user can remove all sources and redefine their ac- 
tivity levels without requiring a recompilation or restart of LUXSim, which allows for serial 
processing of multiple simulations without quitting the program. This feature is useful on 
computer clusters with a managed job queueing, where it may take some time for the job 
to start. 

To add a source to the simulation, the user specifies the component name, and the name 
and activity of the generating source to put in the component. For example, the command 
to load a 100 mBq/kg AmBe source on a specific PMT window is "/LUXSim/source/set 
Bottom_PMT_Window_39 AmBe 100 mBq/kg". The volume names are keyed to the physical 
volume name as set in the LUXSimDetectorComponent declaration. Activity units of Ci or 
Bq with standard SI prefixes are accepted, while the per unit mass is optional. For the case 
of the activity being defined per unit mass, the mass itself is automatically calculated based 
on the Geant4 geometry and material density. The age of the source can also be specified 
at the end of the command (e.g. for the "U238Chain" generator, one might add "2 Gyr"). 
Radioactive loads can be placed on individual components, such as a single PMT cathode, 
by using the full component name (e.g., "Bottom_PMT_Window_12"). Alternatively, one can 
place the same radioactivity levels on multiple components using any part of the component 
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1 name, e.g. the command "/LUXSim/source/set Bottom_PMT .Window AmBe 100 mBq/kg" 

2 will place the specified AmBe activity on all bottom PMT windows. The LUXSimManager 

3 keeps a record of the total activity for each component, and each component keeps the record 

4 of the sources it contains. In keeping with the LUXSim guiding principles, this function- 

5 ality is automatically available for all components cast as a LUXSimDetector Component, 

6 requiring no additional coding on the part of a developer. 

7 When an event is to be generated, Geant4 calls the LUXSimPrimaryGeneratorAction 

8 class, which in turn passes the call on to the LUXSimManager, along with the required 

9 pointers to the manager class. The LUXSimManager chooses one detector component to 

10 generate an event position; the component selection is random, but weighted by the total 

11 activity of each component. The manager passes the event generation pointers to the selected 

12 component. The component selects a position within its own geometry to generate the decay. 

13 The component class also randomly chooses a source type, again weighted by the activities of 

14 all sources in that component. The component calls the appropriate LUXSimSource object, 

15 which specifies particle type, energy, and direction. Finally, with the particle position, type, 

16 energy, and direction specified, the source object calls the Geant4 generator, passing all the 

17 required primary particle information. 

18 1. Single-nuclide decays 

19 All single-isotope decays are handled in a single method of the LUXSimSource class. 

20 This method takes advantage of the built-in Geant4 Radioactive Decay Manager (G4RDM), 

21 which contains all the isotope decays from the Evaluated Nuclear Structure Data Files [27] . 

22 The G4RDM provides a, (3, and 7 decays from both excited- and ground-state nuclei. The 

23 G4RDM also takes as input the range of mass number and charge over which a nucleus is 

24 allowed to decay, allowing for a decay of just the parent nucleus, decays all the way to a 

25 stable nucleus, or somewhere inbetween. 

26 The macro command used to specify the decay must include the atomic mass and number. 

27 For example, to create decays, one would use "SingleDecay_40_19" . As with all macros, 

28 this command is parsed by the LUXSimManager. The generator uses G4GPS to define the 

29 particle as the requested isotope in an uncharged, ground state. When using this macro 

30 command, LUXSim sets the nuclear decay limits to just the parent isotope, rather than any 
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1 possible extended chain of decays. After giving the isotope zero energy, the event is started 

2 with the usual call to the Geant4 method GeneratePrimaryVertex. 

3 2. Th and U decay chains 

4 A common approach to decay chain generation within Geant4 is to simply use the 

5 G4RDM. One particular concern in decay chains is position correlation — if the radionu- 

6 elides are trapped within a bulk material, then a daughter decay should occur at the same 

7 location as the parent decay. If full position correlations are required, the chain is allowed 

8 to decay to the last, stable isotope. If position correlations arc not required, single decays 

9 may be created at random throughout the decay chain. Individual experiments may slightly 

10 alter these basic approaches based on detector response, activity levels, and so forth. 

11 These two approaches of correlated-position and uncorrelated-position decays each have 

12 disadvantages that were avoided within LUXSim. In the correlated-position approach, a 

13 required input for accurate decay chain generation is the age of the source. If the source 

14 age is large compared to the time between decays, many unnecessary decays are simulated 

15 before the age of the source is reached. This requires computation time on simulated events 

16 that will ultimately be discarded from the analysis. Another disadvantage is that multiple 

17 traversals of the decay chain result in temporally interspersed events. For example, the 

18 ^^^Ra decay from a traversal of the '^^'^Th decay chain may occur before the ^^^Ac decay 

19 from another chain. This becomes an issue if two decays from different traversals of a decay 

20 chain occur within the event pileup window of the detector. Thus the events recorded to 

21 disk must be post-processed to arrange them in chronological order, and the computation 

22 overhead to time-order millions to billions of events may be substantial. 

23 The uncorrelated-position approach, using random decays within the chain, avoids both 

24 the problem of simulating unnecessary decays and having to time-order the events in post- 
25 processing, but it unfortunately loses the position correlations between individual decays. 

26 Extrapolations can be performed to minimize the effects of losing position correlations. 

27 These extrapolations, however, require detailed knowledge of the detector response and 

28 specific source activity levels. The resulting decay chain generator is therefore single-purpose, 

29 and cannot be used in simulations of other detectors that do not have near-identical operation 

30 and response. 
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FIG. 5. Decay activities of selected isotopes within 
the '^^'^Th. decay chain. In this figure, the source has 
an age of 1 half hfe of ^^^Ra, or 5.75 years. The ver- 
tical dashed line marks 10 half lives from a source 
age of years. The source age can be arbitrarily 
set without additional computational requirements. 
Figure taken from Ref. |28| . 

1 LUXSim avoids all these disadvantages by using a general-purpose decay chain genera- 

2 tor that exhibits accurate timing and maintains position correlations, without simulating 

3 discarded events or requiring chronological post-processing. The LUXSim decay chain gen- 

4 erator uses the source age and activity level of the parent isotope as inputs. The approach 

5 used combines analytic and stochastic methods to create a time-ordered record of all decays 

6 before a single event has been generated. This approach is fully documented in Ref. [28] . 

7 including benchmarks and memory usage analysis. A sample plot of isotopic activity levels 

8 from the ^ss^j cj^ain is shown in Fig. [sj 

9 3. AmBe neutrons 

10 The AmBe generator in LUXSim produces neutrons with a representative spectrum along 

11 with the accompanying high-energy gamma rays. The 60-keV gamma rays associated with 

12 the decay of ^^^Am are not included in this generator. If such decays are required, a basic 

13 americium source can be loaded into a detector component, along with this nominal AmBe 

14 source, with the appropriate activity ratios. Self-shielding effects can be created naturally 
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FIG. 6. Spectrum of neutrons from an AmBe 
source. This spectrum was digitized and used in 
the LUXSim AmBe event generator. Figure taken 
from Ref. [29]. 



by creating a detector part made of americium-beryllium material, and loading that volume 
with the AmBe source. If a point source is desired, the volume can be made nonphysically 
small (e.g., an angstrom in extent). 

The neutron spectrum comes from Marsh et al. [29] , and is reproduced in Fig. [6] This 
spectrum was digitized and normalized in order to create a cumulative distribution function 
(CDF) with a neutron endpoint energy of 11 MeV. Within the generator, a random number 
between and 1 is generated, and the CDF is used to associate that random number with 
an energy. A linear interpolation is used between the discrete energy values. This method 
of spectrum sampling was used because the sample space is somewhat sparsely populated, 
and requires creating just one random number that is converted to a neutron energy. 

The neutron spectrum can depend greatly on the source geometry, especially for the 
lower-energy neutrons caused by break-up reactions. Even so, this neutron spectrum was 
selected as representative of the large majority of AmBe sources available, and any deviation 
from this reference source would have to be measured for each individual source. 

(a, n) reactions within the AmBe source can be accompanied by 0, 1, or 2 gamma rays, 
depending on the energy level of the resulting ^^C nucleus. The associated gamma energies 
were taken from the NuDat data base [30], and the ^^C energy level structure from the 
Isotope Explorer [31]. The number of gammas produced in coincidence with a neutron is 
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a function of the neutron energy, and comes from Geiger and Zwan [32]. Neutrons with 
energy up to 0.5 MeV are not accompanied by gamma rays, as they are classified as break- 
up neutrons. Neutrons with energy between 0.5 and 1.9 MeV are associated with a ^^C 
nucleus in the 7654-keV energy level, and this nucleus relaxes via emission of 3215- and 
4439-keV gamma rays. If the neutron has energy between 1.9 and 6.0 MeV, the ^^C nucleus 
is in the 4439-keV state, and decays via emission of a single gamma ray. Neutrons above 
6.0 MeV are not accompanied by gamma rays. 

When two gamma rays are emitted, the LUXSim AmBe generator takes into account the 
angular correlations between these gamma rays. The 7654-keV level is a 0"^ state, the 4439- 
keV is 2+, and the ground state is again 0"^, meaning both nuclear relaxations are electric 
quadrupole transitions. Because the parent ^^C nuclei are considered to be non-polarized, 
a random direction is selected, and the individual gamma emission angles distributed from 
that random angle via the appropriate Legendre polynomial equation. 

4- Fission generator 

The fission generator is modeled on a 252Qf source. The fission generator does not repro- 
duce a full 252q£ source, but only creates neutrons and gammas associated with spontaneous 
252q^ fission. Similar to the AmBe generator, a full 252Qf source can be created by loading a 
simple 252Qf source onto a source volume along with this fission generator in the appropriate 
ratio. Currently, only the 252Qf generator is available in LUXSim. Others can be added 
using the approach and references contained in this section. 

The multiplicity of the neutrons has a mean value of 3.757, as reported in Valentine |33] . 
while the energy of the individual neutrons is described by a Watt spectrum: 

dN/dE = e(-^/i-209)sinhV0.836E (1) 

where E is in units of MeV. The neutron spectrum is shown in Fig. [7] The parameters for 
Eq. ([T]) come from Mannhart [51]. The energy range extends from 1 meV to 15 MeV. Because 
the spectrum takes on an analytic form, selecting from it at random is handled differently 
than the neutron spectrum of the AmBe generator. The maximum value of Eq. ([T| is slightly 
below 0.48, so a random coordinate is chosen with x ranging from to 15 and y ranging 
from to 0.48. If this coordinate point lies below the neutron energy curve, that energy 
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is selected as the event's neutron energy. Otherwise, a new coordinate point in the same 
(x, y) range is chosen at random. This method of spectrum samphng was used because the 
available parameter space is roughly 50% filled. If the parameter space were appreciably 
less than 50% filled, a CDF would have been used instead, in the manner of sampling from 
the AmBe neutron spectrum. 

The neutron multiplicity of a fission event defines the total energy of the gammas released 
in the fission event via the equation 



ETot,y = (2.51 - 1.13 X IQ-^Z^VAJ V + 4.0 MeV (2) 

where Z and A are the atomic number and weight of ^^^Cf, and v is the number of emitted 
neutrons. Eq. (|2]) is an empirical fit to the data, and there is no physical justification for its 
form [33] . Valentine collates a few measurements of the average total gamma energy released 
in the fissioning of ^^^Cf, and determines a best-fit value of 6.95 ±0.3 MeV [a = 4.32%). We 
therefore apply a 4.32% Gaussian spread to the total energy in any given simulated ^^^Cf 
event within LUXSim. 

The average energy of the emitted gammas is calculated with the equation 



{E^} = -1.33 + 119.6 Z^/yA MeV (3) 

To obtain the fission gamma multiplicity, the total energy is divided by the average energy 
for each event, and the resulting number is used as the mean of a Poissonian distribution, 
with an integer number of gammas determined stochastically from this distribution on an 
event-by-event basis. 

The energy of the gammas is determined from the 252Qf spectrum available from Verbinski 
et al. [35J. The fission gamma spectrum extends to roughly 7 MeV, and within LUXSim, 
this spectrum is sampled at random for every gamma, with the restriction that the total 
energy must add up to that determined via Eq. ([2]). The gamma spectrum is shown in Fig. [7| 
Because the parameter space for gamma energies is somewhat sparse, we used a CDF and 
a single random number to sample from the spectrum. 
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FIG. 7. Neutron and gamma ray energy spectra from spontaneous fission 
decays of ^^^Cf. The neutron spectrum comes from Eq. ([T]), and the gamma 
spectrum is from Ref. |35j . The curves are not correlated to each other in 
amplitude, and merely display their relative shapes. 

1 5. Cosmic muons and spallation neutrons 

2 The cosmic muon and spallation neutron generator produces either muons or spallation 

3 neutrons spread randomly throughout the rock-cavern interface. The equations governing 

4 particle characteristics discussed in this section come from Mei & Hime The through- 

5 going muon flux is given as 



I{h, d) = (Jie-^/^^ + /2e-'^/^2)sec(^) (4) 

6 where Ii and I2 are differential muon intensities at depth h, Ai and A2 are attenuation 

7 constants, h is the slant depth {h = sec{9), where Hq is the vertical depth), and 9 the 

8 slant angle. A fiat over-burden has been assumed. For the Homestake site, h = 4.3 km 

9 water equivalent is used. Eq. (|4]) is a fit function to the available experimental data. The 

10 muon's incident angle is determined by sampling from equation Eq. Q. Once the angle has 

11 been assigned, the muon energy is sampled from 

^ = Ae-'^^^^-'\E, + e^(l - e-''^)^'^ (5) 

12 where A is a normalization constant, Efj_ is the muon energy, and b, 7^, and are parameters 

13 detailing energy loss through rock. Once the muons are generated, they are handled by 
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1 the internal Geant4 code. The Geant4 code itself handles various interactions, including 

2 spallation neutron production. 

3 Through the use of a macro command, users have the option of generating spallation 

4 neutrons as primary particles instead of cosmic muons. An event site is chosen at random 

5 throughout the cavern volume, and the neutron energy, angular distribution, and multiplicity 

6 are sampled from Mei & Hime Eqs. (14) and (15), (16)-(18), and (19)-(22) respectively. 

7 Although spallation neutrons are created over a lateral range extending meters away from 

8 the muon track, a single event site is appropriate for fast, order-of-magnitude calculations. 

9 6. Primary scintillation and ionization 

10 The model of scintillation and ionization must be as accurate as possible to provide 

11 realistic calculations of the detector response. The basic installation of Geant4 incorporates 

12 a model for scintillation light production [HTf EH], although it has some deficiencies that 

13 were addressed within LUXSim. As discussed in the section, however, the ionization model 

14 is wholly inadequate for dual-phase detectors. 

15 In standard Geant4, the number of scintillation photons created per unit of energy loss is 

16 set by the user for each material and particle type. Unfortunately, this ability to distinguish 

17 between particles only applies to protons, electrons, deuterons, tritons, alphas and a generic 

18 ion particle definition [3H1 ES] • More specifically, xenon nuclei scintillation parameters cannot 

19 be uniquely defined in standard Geant4. In dual-phase detectors, the scintillation yield is 

20 also a function of the applied electric field; a strong electric field reduces recombination, 

21 but recombination of ionized electrons leads to scintillation. Geant4 does not allow for this 

22 E-field dependence. Furthermore, while the Geant4 scintillation model allows us to set the 

23 ratio of long and short decay constants as a function of particle type, it does not allow for 

24 variability with respect to particle energy. 

25 The Geant4 scintillation model depends entirely on user definitions. The parameters such 

26 as yields, decay constants, and output spectrum are not distributed with Geant4 itself. It 

27 falls to the user to evaluate all available publications to determine the best parameters for 

28 xenon scintillation. These parameters are entered in the form of arrays, with interpolations 

29 performed between data points. 

30 In addition to scintillation deficiencies, the standard Geant4 physics models are incapable 
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1 of tracking ionization electrons below 250 eV. Rather, if any number of low-energy electrons 

2 are created below this cutoff value, they deposit all their energy in a single point without 

3 any tracks being created. Because the ionization electrons created by a xenon recoil have 

4 energy in the 10-eV range [H], the electromagnetic physics models in Geant4 are not directly 

5 applicable to a dual-phase detector. Likewise, Geant4 does not allow for drifting electrons, 

6 as their energy is comparable to that of the initial ionization electrons [lO] . 

7 To obtain a more accurate scintillation and ionization yield for a wide variety of situa- 

8 tions in dual-phase xenon, the Noble Element Simulation Technique (NEST) code was devel- 

9 oped [12] and implemented in LUXSim. NEST uses energy-, particle-, and field-dependent 

10 models to determine scintillation and thermal ionization yield. It is applicable to both elec- 

11 tron and nuclear recoils with energies 0(1 keV) to 0(1 MeV), as well as varying electric fields 

12 from to ~10 kV / cm. NEST offers LUXSim and similar applications a recombination 

13 model that is vetted against all known available experimental xenon data, making additional 

14 user input unnecessary. The best comprehensive results were used in the scintillation and 

15 ionization yield equations, which replace the Geant4 approach of using arrays to define the 

16 scintillation parameters, and thus avoiding interpolation. 

17 Through the use of NEST, LUXSim is able to create both light and charge yield in a 

18 realistic fashion under a wide variety of conditions and parameters. This will allow LUXSim 

19 to perform simulations of the full chain of events, from initial particle interactions in the 

20 liquid, to drifting electrons, to the production of secondary scintillation light. 

21 E. The physics list 

22 LUX is a low-background experiment, and like most such experiments, it will be located 

23 in an underground laboratory. The theoretical scale of nuclear recoil energies from WIMP 

24 interactions is in the 1-100 keV range, and as such, LUXSim employs physics models that 

25 extend to these lower energies. At the same time, however, underground experiments must 

26 also contend with high-energy cosmic muons that survive the kilometer-water-equivalent- 

27 scale overburdens. These tend to have energies in the hundreds of GeV range. LUXSim 

28 must therefore also be able to handle high-energy interactions. Neutrons creating nuclear 

29 recoils are a background to the WIMP signal, and they must be handled over a range of 

30 energies from thermal to hundreds of MeV. LUXSim must also be able to properly generate 
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1 and handle optical photons, as well as radioactive decays. 

2 LUXSim calls up the appropriate physics lists via the modern list factories available 

3 starting in GEANT version 4.9.2. For low-energy electromagnetic interactions, LUXSim 

4 makes use of the Livermore physics list. Details of the Livermore list, as well as other lists 

5 described in this section, are, unless stated otherwise, available in the Physics Reference 

6 Manual [37j, with implementation options described in the Users's Guide for Application 

7 Developers [38] . 

8 The high-energy models must handle interactions such as spallation events, elastic coUi- 

9 sions, and short-lived particles and their decays. LUXSim makes use of the QGSP_BIC_HP 

10 list. These terms stand for, in order, "Quark-Gluon String Precompound" , "Binary Cas- 

11 case" , and "High-Precision" . QGSP provides string models for hadrons above 5-25 GeV, and 

12 parameterized models for lower energies. The Binary Cascade models are used for protons 

13 and neutrons below 10 GeV. The High-Precision models are data-driven models for neutron 

14 transport from 20 MeV down to thermalization. The QGSP_BIC_HP list does not handle 

15 relaxation of nuclei resulting from neutron captures. Processing of excited-state nuclei is 

16 handled via separate hadronic models. 

17 The optical physics list was created in consultation with Peter Gumplinger, and is based 

18 on the field04 extended example included as part of the Geant4 distribution. The optical 

19 physics list includes absorption, Rayleigh scattering, and boundary processes. It also al- 

20 lows for the generation of optical photons via either Cherenkov production or scintillation. 

21 Because a large number of optical photons can be generated with even modest energy de- 

22 positions, the optical photon generation can be turned on or off at run time via LUXSim 

23 macro commands to speed up the simulation if optical physics is unnecessary. A simplified 

24 optical physics model is also available for selection at run time. The details of this model 

25 are covered in Section TlV C[ 

26 An often-used parameter within the Geant4 physics list is known as the "cut value" . This 

27 is the energy below which secondary particles are no longer created. Because particles will 

28 have different ranges for the same energy depending on the medium, the cut value is set 

29 as a length rather than an energy, and can be set separately for different particles. The 

30 default setting within LUXSim is 5 fim for gammas, electrons, and positrons, and 100 fim 

31 for protons, a's, and generic ions. Using a short cut value can greatly increase the simulation 

32 run time. If tracking at the 5-/im level is not required, the cut value for gammas, electrons, 
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and positrons can be set to 100 /xm at run time via LUXSim macro commands. There is no 
apparent increase in simulation speed for increasing the cut value above 100 fim. 



F. Event processing 

Event processing is handled via the usual Geant4 methods UserSteppingAction, Be- 
ginOfE vent Action/EndOfE vent Action, and BeginOfRunAction/EndOfRunAction. Within 
the stepping action, individual steps, interactions, and energy depositions are stored in mem- 
ory for later processing. While there can be a very large number of steps within a single 
event, the number rarely goes above hundreds of thousands, even for high-energy events. 
While this requires hundreds of megabytes of computer memory, it is easily within the capa- 
bilities of any modern desktop or laptop. The stepping action also kills particles and tracks 



under certain circumstances, if requested by the user (see Section IV G). 

The event action prints out periodic progress reports, and after all steps have been stored, 
it calls on the manager to determine what data from the full collection of any given event 
needs to be written to disk. Finally, the store of data is cleared from memory in anticipation 
of the next event. A great deal of the work of the run action has been incorporated into the 
manager methods, so the run action's only function is to print start and stop times to the 
screen. 



G. Data recording 

LUXSim includes a specific class, LUXSimOutput, to process the step information that 
is recorded during an event. The output file itself is a custom- format binary file. It includes 
two groups of information. One group is the header which records the information about 
the run, and includes the following: 

• A time/date stamp of when the simulation was run 

• The versions of Geant4 and LUXSim 

• The computer information, including name and operating system, on which the sim- 
ulation was run 

• The macro command used in setting up the simulation 
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FIG. 8. Flow chart of data recording in LUXSimOutput class. The numbers 
in parentheses represent the optical record level. 

• All the differences between that version of LUXSim and any changes that might have 
been made to the code directly 

• A detector component ID lookup table 

The final item in this list, the ID lookup table, is included to save disk space. Volumes from 
which steps are recorded are not referred to by their string names, but by a numerical ID 
which is defined in the header. 

The vast majority of recorded information is from the results of the simulation itself, 
on a volume-by-volume basis, and is written after every event. LUXSimOutput determines 
how much information to record according to the record levels defined by the user in the 
macro command file. A flow chart for the data recording is shown in Fig. |8| There are two 
independent record level categories, one for optical photons, and one for all other particles. 
This separation is necessary because optical photons are handled in ways distinct from 
other particles within Geant4, in terms of energy conservation, ionization, and fundamental 
physical processes. These record levels tell the output class what information to record for 
each detector component. 

For Optical Photons: 

• Optical Record Level = - Do not record (default) 
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• Optical Record Level = 1 - Record just the total number of optical photons entering 
the volume, and kill the track so the photons do not propagate 

• Optical Record Level = 2 - Record just the total number of optical photons entering 
the volume but do not kill the tracks 

• Optical Record Level = 3 - Record all the information on the optical photons entering 
the volume and kill the tracks 

For normal particles: 

• Record Level = - Do not record (default) 

• Record Level = 1 - Record just the total energy deposition in the current volume 

• Record Level = 2 - Record just the steps where energy was deposited 

• Record Level = 3 - Record all the steps, even those with no energy deposition 

• Record Level = 4 - Record all the information about the particle, then kill the track 

Using record level 4 for ordinary particles, or optical record level 3 for optical photons, is 
used primarily for debugging purposes, or when we are not necessarily concerned about what 
happens inside a detector component, and simply want to know the flux of particles into 
the component. 



V. POST-SIMULATION DATA PROCESSING 



The geometries in LUXSim accurately recreate their physical counterparts, and the op- 
tical photon physics list provides accurate handling of the optical photons. To complete 
the simulation chain, we developed a detector response module to convert the LUXSim out- 
put files into detector-like data files, taking into account the response of the actual PMTs, 
electronic noise levels, pulse shaping, and triggering. This module is separate from the 
Geant4-based LUXSim code, and it is run on the output data from LUXSim. Our aim was 
to create data that is functionally identical to the actual experimental data, and can be 
processed with our standard experimental data analysis routines. 

The output of the simulated detector response has a binary format that mirrors the format 
of the detector data as written by the DAQ and is the starting point of the experimental data 
analysis. The data is stored as a collection of digitized waveforms, as shown in Fig. |9| which 
can be used to develop, compare to, and test the collaboration's analysis tools. The digitized 
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waveforms were compared to XENON 10 data because of the similarity of the detectors. Both 
LUX and XenonIO are dual-phase xenon detectors with arrays of PMTs at the top and 
bottom, and thus the SI signals from both detectors have similar characteristics. The 
simulated data stream allows us to test analysis and reconstruction algorithms. 

Single-photon PMT responses are taken to be Gaussian in shape. A multiple-photon 
event is constructed by summing together single photoelectron responses for each photon 
that hits a PMT window. This results in the analog signal that is read from the full collection 
of PMTs. Simulation of amplifiers and shapers deliver the signal to a simulated digitizer. 
A frequency-independent noise of 155 yuV RMS is added to the input of the digitizer. The 
simulated signals are based on the shaped single photoelectron response as measured from 
the LUX electronics. Figure |9] shows a simulated detector response to individual 30-keV 
electrons placed in the middle the liquid xenon. The LUXSim data was converted so that 
it mimics the experimental data that traversed the analog electronics and data acquisition 
system. The scintillation time constants are the cause of the tail of the SI pulses. 
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FIG. 9. The simulated LUXSim SI response after post-processing (top), 
and a measured SI signal from XenonIO (bottom) [33]. The horizontal 
axes show elapsed time since the trigger. The thick dashed line shows an 
average response for 502 (319) SI pulses from LUXSim (XenonIO) scaled 
by a factor of 2 x 10"^ (7 x 10"^), with the response from the individual 
channels of single event in multi-colored lines. The scale factors are different 
because of differences in the energy deposition and the number of summed 
curves. A 29-ns decay curve is overlaid on both sum curves to show the 
measured scintillation relaxation time of liquid xenon. 
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VI. EXERCISING THE LUXSIM SOFTWARE 



With all the machinery of LUXSim in place, we exercised the software both to compare 
its results to experimental data, as well as to make predictions regarding the light collection 
of the LUX detector. These exercises are not intended to provide a full validation of the 
code, but rather to demonstrate basic functionality of the software, and to demonstrate that 
LUXSim provides reasonable results. LUXSim will be updated to incorporate experimental 
results as they become available. 

This section is not intended as an exhaustive exploration of Geant4 performance, as such 
studies are available in the existing literature. Various groups have compared experimental 
data with Geant4's electromagnetics [H], neutron spallation and transport code [H], and 
hadronic shower models [IB] . Many other comparisons exist within the literature, and those 
referenced here are intended simply as examples from the larger body of work. The Geant4 
collaboration itself maintains a list of publications covering model verification |47j . 



A. LLNL single-phase detector 

We have compared experimental and simulation data of an argon/nitrogen gas propor- 
tional scintillation counter with an ^^Fe X-ray source. This detector was a single-phase 
system used as a testbed to study secondary scintillation, similar to the secondary signal 
produced by the LUX detector. The details of operation of the detector and data analysis 



methods are described in Ref. Fig. 10 shows a photograph of the experimental setup, 
and the corresponding LUXSim geometry. 

The ^^Fe source emits 6-keV X-rays which interact via the photoelectric effect, ejecting 
3 keV electrons. The excited argon atoms relax via emission of either Auger electrons or by 
secondary X-ray emission. In the latter case, the X-rays may escape the detector, leaving 
behind a total energy deposition of only 3 keV. The SI signals from these energy depositions 
were too weak to observe, but we constructed a spectrum from the S2 signal. 

In the experimental data, we were able to observe a spectrum with two main features: a 
large peak corresponding to the 6 keV X-rays, and a smaller peak corresponding to escape 
events. These peaks were generated by LUXSim as well, in good agreement with experi- 



mental data (see Fig. 11). To get the centroids of the experimental and simulation 6-keV 
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FIG. 10. A photograph and a LUXSim rendering of the gas proportional 
scintillation counter used to study secondary scintillation light. The ^^Fe 
source is located in a moveable collimator, shown at the end of the acrylic 
swing arm. The secondary scintillation volume is bounded by the large, 
toroidal field-shaping rings below the large steel flange. The acrylic support 
rods and swing arm have been left out of the simulation, as their effect on 
the collimated X-ray source is negligible. The collimator, however, is visible 
in both images. 

peaks to match, the number of scintillation photons emitted / mm / ionization electron 
had to be set to 0.146. This was the only free parameter in the fit — the peak widths and 
relative amplitudes between the primary and escape peaks were predicted by LUXSim. The 
simulation did not include a quantum efficiency cut, and given the PMT's quantum effi- 
ciency of 27% at the characteristic nitrogen range of 340-360 nm, we estimated the number 
of scintillation photons emitted in the physical detector to be approximately 0.54 / mm / 
ionization electron. 

For this comparison between LUXSim and the experimental results, we constructed a 
rudimentary S2 signal generator by producing optical photons along a vertical line through 
the S2 volume. The (x, y) position of this line was based on the location of energy deposi- 
tions in the active gaseous volume, while the z extent was defined by the top and bottom of 
the S2 volume. We were not able to make use of the NEST code described in Section HVD 61 
because the medium in the single-phase detector was argon and nitrogen, rather than xenon. 
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Number of optical photons 

FIG. 11. Comparison of the experimental and LUXSim S2 spectra from 
an ^^Fe source. The two main features are a large peak near 180 optical 
photons corresponding to a ~6-keV energy deposition, and a small peak near 
90 optical photons corresponding to the ~3-keV escape peak. The shaded 
regions show the uncertainty in the experimental data, and the smooth lines 
on each curve are fits to the data. 

The resolution of the Monte Carlo curve was based solely on the number of optical pho- 
tons detected. This implies that the width of the 6 keV peak in the experimental data is 
dominated by counting efficiency, in agreement with existing literature We conclude 
that maximizing light production and collection is the most effect means of improving the 
detector's resolution. 

B. Light collection in LUX 

Because scintillation light is generated isotropically, most of the SI light will at some 
point reflect off the walls, making detector response highly dependent on wall reflectivity. 
LUXSim was used to characterize scintillation photon reflectivity properties from the PTFE 
walls of the detector. 

One question currently being studied is the effect on the total light collection of dif- 
fuse versus specular reflection from the PTFE walls. Silva et al. have developed a model 
governing precisely this issue based on measurements of reflectivity for PTFE for various 
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manufacturing and processing methods [19]. Though this model is available, we can use 
LUXSim to explore extreme cases of reflectivity, such as the effects of 100% diffuse versus 



100% specular reflection on light collection. Figure 12 shows the difference in geometric light 
collection efficiency for these two extreme cases. While LUXSim will strive to incorporate 
the best model of reflection available, the largest ratio between the two curves is about 
1.05, demonstrating that the overall reflectivity of the PTFE has a much larger effect on 
light collection than the specific model of reflectivity used. In particular, the curve increases 
most strongly when reflection goes above 90%. This strong response at high reflectivity is 
associated with individual optical photons bouncing multiple times from the PTFE walls. 
For example, consider an optical photon that bounces five times from the PTFE walls. With 
a reflectivity of 90%, the chance of absorption is 41%. This chance of absorption drops to 
23% for 95% reflectivity, and just 5% for 99% reflectivity. 
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FIG. 12. LUXSim calculation of the geometric light collection efficiency as 
a function of total PTFE reflectivity. The two curves represent extreme 
reflection models: 100% diffuse and 100% specular. The reflectivity of the 
PTFE plays a much greater role in overall efficiency than the reflectivity 
model used. The largest ratio between the curves, ~1.05, is attributed to 
the effects of Rayleigh scattering in the liquid, which reduces the differences 
between specular and diffuse reflection. The uncertainty on the data points 
is less than 1% (relative), and is therefore much smaller than the size of the 
data points. 



37 



The curves in Figure [12] were generated using the default optical parameters described 



2 in Section JVC The relatively small difference between the two curves in this figure are 

3 understandable from the standpoint of the 30-cm Rayleigh scattering length in the liquid 

4 xenon. The randomness introduced by diffuse reflection is comparable to the randomness 

5 introduced by Rayleigh scattering, such that even with a perfect, specular reflector, the 

6 optical photons tend to scatter multiple times along their path length. 

7 A second study of light collection determined the qualitative effects of interaction location 

8 on detector response. If scintillation light is created close to a bank of photomultiplier tubes, 

9 the solid angle subtended by the tubes is relatively high, leading to a larger signal response 

10 than if the energy deposition were farther from the PMTs. This effect is counter-acted in part 

11 by the grid planes being most transparent at normal incidence, which implies that a higher 

12 percentage of light generated close to the PMTs would be absorbed by the individual grid 

13 wires. Complicating these issues are effects such as total internal reflection off the liquid 

14 / gas boundary, Fresnel reflection off the PMT windows, the aforementioned reflectivity 

15 models and scattering length, and the effects of discretized active PMTs. 



16 Figure 13 shows the difference in light collection as a function of drift time. To obtain 

17 the drift time, we assumed a typical drift speed of 2 mm / /is [50j. The drift time is longest 

18 when the SI scintillation was created at its lowest vertical position. Thus a drift time of fis 

19 implies deposition in the gas volume, while a drift time of 250 fis implies scintillation created 

20 50 cm below the liquid surface, near the bottom bank of PMTs. As we would expect, the 

21 closer to the bottom the energy deposition, the higher the light collection on the bottom 

22 PMTs, and the lower the collection on the top PMTs. As in Fig. |9| the XenonIO detector 

23 provides an apt comparison because of the detector similarities. Within LUX, these response 

24 curves will be measured in situ with appropriate calibration sources to generate a detector 

25 response map. We have implemented this level of detail in LUXSim to better understand the 

26 systematic effects of light collection that can be used to improve LUX or future detectors. 
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FIG. 13. Relative light collection versus drift time 
for the Xenon 10 detector (bottom) [43J, and as 
calculated for the LUX detector by LUXSim (top). 
The maximum drift time is greater in the LUX de- 
tector than the Xenon 10 detector because of the 
greater height of the active liquid xenon volume. In 
the top plot, the dashed vertical line represents the 
liquid / gas interface, and the points that fall near 
this line were actually slightly above this interface, 
which explains the discontinuous trend in the data. 
Compare the triangles (squares) in the top plot to 
the upper (lower) curve in the bottom plot. 
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1 VII. EXPANSION TO OTHER LOW-BACKGROUND EXPERIMENTS 



2 Because of its object-oriented nature, Geant4 provides great power for code re-use and 

3 compartmentalization. LUXSim capitalizes on this framework by respecting object-oriented 

4 programming practices. As a result, it is relatively simple to create a new geometry within 

5 LUXSim. Fully-developed Geant4 simulations may utilize custom methods and functions 

6 that control the geometry of the simulation. While these individual cases may require 

7 the custom code to be incorporated into LUXSim, the procedure to integrate an existing 

8 geometry is given by these steps: 



9 1. Perform a global search-and-replace in the existing geometry code base, replacing all 

10 instances of "G4PVPlacement" with "LUXSimDetectorComponent" 

11 2. Port over any macro commands specific to the existing geometry 

12 3. Port over any custom event generators if they do not already exist within LUXSim 

13 4. Alter the existing LUXSim geometry code base to reference the new geometry 



14 This last step is a very simple procedure, typically involving editing only 5-10 lines of code 

15 in total. With these four steps completed, users would be able to control the running of 

16 the simulation using the standard LUXSim macro commands. These commands automati- 

17 cally allow the user to set up component-centric event generation and recording at run time, 

18 without recompilations between simulations. The header information would be automati- 

19 cally written to the output file, greatly aiding reliability and reproducibility. 

20 As additional experiments use LUXSim, we will incorporate additional physics models and 

21 materials, expanding the range of applicability. For example, it would be straightforward to 

22 incorporate optical parameters specific to argon and neon, making LUXSim appropriate for 

23 use in all noble-element WIMP searches. By simply porting in specific geometries and their 

24 associated material definitions, LUXSim can provide a very powerful simulations package 

25 for new or existing neutrinoless double-beta decay experiments. 

26 The long-range plan for LUXSim includes making the code base pubhcly available, after 

27 the vetting process is complete. Until the code is available for download, inquiries for code 

28 access may be sent to the corresponding author. 
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1 VIII. SUMMARY 



2 LUXSim is an object-oriented simulations package based on Geant4. It involves expand- 

3 ing on the Geant4 classes to make Geant4 more immediately useful for low-background 

4 simulations. This expansion includes recording component-specific data, which allows for 

5 multiple source types and activities, various record levels, and automatic registration with 

6 the manager class. Newly-developed classes allow for a novel approach to event gcncr- 

7 ators, allow for time-sequential processing, and minimize simulation time, file size, and 

8 post-processing. 

9 We have presented an overall philosophy for guiding the development of the simulation 

10 software, clarifying and optimizing workloads, for both users and developers. These guiding 

11 principles were based primarily on case of use, reproducibility, and physics requirements 

12 specific to low-background detectors with signals in the 1-keV to 10-MeV energy range. We 

13 have shown how the software architecture was guided by these principles, taking advantage 

14 of the object-oriented nature of C-|— I- and Geant4 to make the code scalable while at the 

15 same time reducing the likelihood of coding errors. 

16 We described the various subsystems and how they participate in the information flow 

17 within the simulation. We included details of event generation and recording, the physics 

18 models available within the simulation, and options for operating in a simplified physics 

19 mode for debugging purposes. We have also included geometry examples based on the LUX 

20 detector and associated projects. 
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